Previous slide Next slide Toggle fullscreen Open presenter view
Banco de Dados Aula 02 - Modelagem Conceitual I (ER básico)
Helder Jefferson Ferreira da Luz
helder.luz@ifpr.edu.br
Objetivos da aula
Entender o propósito da Modelagem de Dados .
Aprender os componentes do Modelo ER: Entidades, Atributos e Relacionamentos .
Identificar tipos de atributos, como chaves primárias , compostos e multivalorados.
Iniciar a construção de um Diagrama Entidade-Relacionamento (DER) .
O que é Modelagem de Dados?
Antes de construir um banco de dados, precisamos de um projeto .
A modelagem de dados é o processo de criar um diagrama que representa a estrutura dos dados e como eles se relacionam.
É como a planta de uma casa: define o que será armazenado e onde.
O Modelo Entidade-Relacionamento (MER) é a ferramenta mais comum para essa etapa.
Componentes do Modelo ER
O modelo ER possui três componentes principais:
Entidades : Os "objetos" ou "conceitos" do mundo real que queremos armazenar.Atributos : As "propriedades" ou "características" dessas entidades.Relacionamentos : As "associações" ou "interações" entre as entidades.
1. Entidades
Uma entidade é qualquer objeto do mundo real sobre o qual desejamos guardar informações. Pense em substantivos.
Exemplos:
Um CLIENTE
Um PRODUTO
Uma MATRÍCULA
Um CARRO
No diagrama, uma entidade é representada por um retângulo .
substantivo : classe de palavras com que se denominam os seres, animados ou inanimados, concretos ou abstratos, os estados, as qualidades, as ações.
2. Atributos
Atributos são as propriedades que descrevem uma entidade. Se a entidade é um substantivo, os atributos são seus adjetivos.
Exemplos para a entidade CLIENTE:
NomeCPFData de NascimentoEndereço
No diagrama, são representados por elipses ligadas à entidade.
adjetivo : palavra que se junta ao substantivo para modificar o seu significado, acrescentando-lhe noções de qualidade, natureza, estado etc.
Atributos - Exemplo
Atributos - Tipos Especiais
Identificador (ou Chave Primária) : Atributo que identifica unicamente cada registro da entidade. É obrigatório e não pode se repetir. Ex: CPF para CLIENTE. No diagrama, seu nome é sublinhado .
Atributo Composto : Pode ser dividido em partes menores. Ex: Endereço pode ser dividido em Rua, Número, Cidade.
Atributo Multivalorado : Pode ter múltiplos valores para o mesmo registro. Ex: Telefone (um cliente pode ter mais de um).
O atributo CPF é o identificador único do cliente.
3. Relacionamentos
Relacionamentos representam a associação entre duas ou mais entidades. Pense em verbos que conectam os substantivos.
Exemplos:
Um CLIENTE faz um PEDIDO.
Um ALUNO cursa uma DISCIPLINA.
No diagrama, são representados por um losango .
Cardinalidade do Relacionamento
A cardinalidade define "quantos de cada lado" participam do relacionamento. Ela especifica o número mínimo e máximo de instâncias de uma entidade que podem se relacionar com uma instância da outra.
Os tipos mais comuns são:
1:1 (Um para Um)1:N (Um para Muitos)N:M (Muitos para Muitos)
Cardinalidade - 1:1 (Um para Um)
Uma instância da Entidade A se relaciona com no máximo uma instância da Entidade B, e vice-versa.
Exemplo:
Um MOTORISTA possui uma CARTEIRA DE HABILITAÇÃO.
Uma CARTEIRA DE HABILITAÇÃO pertence a um único MOTORISTA.
Cardinalidade - 1:N (Um para Muitos)
Uma instância da Entidade A pode se relacionar com várias instâncias da Entidade B, mas uma instância de B se relaciona com apenas uma de A.
Exemplo:
Um CLIENTE pode fazer vários PEDIDOS.
Cada PEDIDO pertence a um único CLIENTE.
(Lê-se: 1 cliente faz 0 ou muitos pedidos)
Cardinalidade - N:M (Muitos para Muitos)
Uma instância da Entidade A pode se relacionar com várias de B, e uma instância de B pode se relacionar com várias de A.
Exemplo:
Um PRODUTO pode estar em vários PEDIDOS.
Um PEDIDO pode conter vários PRODUTOS.
(Este tipo de relacionamento geralmente se torna uma nova tabela no banco de dados! Veremos isso mais tarde.)
Um parêntese: Notações de Modelagem
Existem várias formas de desenhar um diagrama ER. As mais famosas são Chen , Crow's Foot (Pé de Galinha) e UML .
Chen : Acadêmica e detalhada. Usa losangos para relacionamentos e elipses para atributos. Ótima para aprender a teoria.UML : Padrão unificado para modelagem de software. Usa diagramas de classes que são mais complexos e abrangentes.Crow's Foot : A mais popular na indústria. É visualmente intuitiva, representando cardinalidades com símbolos que lembram "pés de galinha".
Usaremos a notação de Crow's Foot por sua clareza e popularidade no mercado de trabalho.
Comparando as Notações (Relacionamento 1:N)
Crow's Foot (a que usaremos):
UML (simplificado):
Na notação de Crow's Foot, a entidade é um retângulo dividido em duas partes:
O nome da entidade.
A lista de seus atributos.
A Chave Primária (PK) é marcada, e se um atributo também for uma Chave Estrangeira (FK) , ele também é sinalizado.
O relacionamento é uma linha que conecta duas entidades. A cardinalidade é representada por símbolos nas pontas da linha:
| : UmO : Zero< ou { : Muitos (o "pé de galinha")
Combinações comuns:
|| : Um e somente um |O : Zero ou um |{ : Um ou muitos O{ : Zero ou muitos
Cardinalidade - 1:1 (Um para Um)
Uma instância da Entidade A se relaciona com zero ou uma instância da Entidade B.
Exemplo:
Um MOTORISTA pode ter uma CARTEIRA DE HABILITAÇÃO.
Uma CARTEIRA DE HABILITAÇÃO pertence a um único MOTORISTA.
Lê-se: Um motorista possui zero ou uma CNH. Uma CNH é possuída por um e somente um motorista.
Cardinalidade - 1:N (Um para Muitos)
Uma instância da Entidade A pode se relacionar com várias instâncias da Entidade B.
Exemplo:
Um CLIENTE pode fazer vários PEDIDOS.
Cada PEDIDO pertence a um único CLIENTE.
Lê-se: Um cliente faz zero ou muitos pedidos. Um pedido é feito por um e somente um cliente.
Cardinalidade - 1:N (Um para Muitos)
Cardinalidade - N:M (Muitos para Muitos)
Uma instância da Entidade A pode se relacionar com várias de B, e vice-versa.
Exemplo:
Um PRODUTO pode estar em vários PEDIDOS.
Um PEDIDO pode conter vários PRODUTOS.
Importante : Como vimos, relacionamentos N:M são "resolvidos" com uma entidade associativa. Veremos isso na próxima aula!
Ferramentas para diagramas
Dúvidas?
Exercícios
Modelagem de uma Biblioteca (Crow's Foot) :
Desenhe um diagrama ER usando a notação de Crow's Foot para um sistema de biblioteca com as entidades LIVRO e AUTOR.
Um autor pode escrever muitos livros, e um livro pode ser escrito por muitos autores.
Liste os atributos principais para cada entidade, incluindo chaves primárias.
Exercícios
Análise de Cardinalidade (Crow's Foot) :
Como você representaria um relacionamento onde um FUNCIONARIO deve gerenciar um e somente um DEPARTAMENTO (e um departamento é gerenciado por um funcionário)?
E se um FUNCIONARIO pudesse opcionalmente gerenciar um DEPARTAMENTO?
Diagrama Completo : Usando a notação de Crow's Foot, desenhe o diagrama para o sistema da loja com CLIENTE, PEDIDO e PRODUTO. Lembre-se que o relacionamento entre PEDIDO e PRODUTO é N:M.
```mermaid
graph TD
A[CLIENTE]
B[PRODUTO]
```
```mermaid
graph TD
subgraph CLIENTE
direction LR
A(Nome)
B(CPF)
C(Data de Nascimento)
end
Entidade[CLIENTE] -> A
Entidade -> B
Entidade -> C
```
```mermaid
graph TD
subgraph CLIENTE
direction LR
A(Nome)
B(<u>CPF</u>)
C(Data de Nascimento)
end
Entidade[CLIENTE] -> A
Entidade -> B
Entidade -> C
```
```mermaid
graph TD
A[CLIENTE] -- faz -> B((PEDIDO))
```
```mermaid
graph TD
A[MOTORISTA] -- 1..1 --- R((possui)) --- 1..1 -- B[CARTEIRA DE HABILITAÇÃO]
```
```mermaid
graph TD
A[CLIENTE] -- 1..1 --- R((faz)) --- 0..N -- B[PEDIDO]
```
```mermaid
graph TD
A[PEDIDO] -- 1..N --- R((contém)) --- 1..N -- B[PRODUTO]
```
**Chen:**
```mermaid
graph TD
CLIENTE -- 1 --- faz(( )) --- N -- PEDIDO
```
```mermaid
erDiagram
CLIENTE ||--|{ PEDIDO : faz
```
```mermaid
classDiagram
CLIENTE "1" -- "0..*" PEDIDO : faz
```
```mermaid
erDiagram
CLIENTE {
int id PK "Identificador"
string nome
string email
string cpf "Identificador único"
}
```
```mermaid
erDiagram
MOTORISTA ||--|o CNH : possui
```
```mermaid
erDiagram
CLIENTE ||--|{ PEDIDO : faz
```
```mermaid
erDiagram
PEDIDO }o--o{ PRODUTO : contém
```